Improved it so even higher values can be used without frame drops.

PR

Master

I haven't yet gotten as far as even testing the setting yet because whoa that's jarring. I'll test now on some lightweight games that I can achieve the targeted fps
(edit reason: My theme might be confrontational. So I'll use a popular one)

You need FPS limiter enabled if it's not capped by the game, also it takes a minute or a few to see results. (slowly reduces CPU usage)
Also this setting is dynamic so you can change it mid-game.

Understood, I'm just showing the QT layout looks broke. Nice to know this is dynamic. Thank you that'll help too.

RPCS3.log
I'm confused your comment says "disabled" by default so do I need to maybe bump the slider to 1? How do I enable?
I've set framelimiter to 30 after trying ps3 native. oblivion.ini has an ifps_clamp set to 30 by default and I haven't changed that I checked to verify. So my game is limiting the fps. And I'm just supposed to play this game, I get close to a perfect 60 fps with when using unlock FPS patch and auto frame limiter, letting the game magically adjust the slider through time. Is 1 hour long enough?

Well the more CPU preemptions, the more effect this pr has, so 0 is no effect at all.

And another factor is the CPU usage so that needs to be observed too. And 15 minutes is fine as well.

It's very lightweight as is. I might need to try a more intense game to get better results.

My thought pattern is along the lines the lighter it is on the hardware the better the results will be because if you're not able to achieve the fps limit you won't get anything.

It's because it doesn't use SPUs. (0 usage)

In my opinion this implementation is a bit too complicated for the end user who will not understand what the option even does. We can move it to advanced tab, but that doesn't achieve the goal here. We really should have just had something easy to tune, a simple "low power mode" checkbox that limits fps to 30 or 60 and calibrates pre-emptions automatically. Even the description of the CPU pre-emptions doesn't help the average user here, they will simply not use it.
Also, we shouldn't have to pre-empt the same way as the other threads at all. If its not rendering and low-power is selected, just pause it automatically. There is no need to calibrate it the way it is done, it seems a bit overkill. Usually RSX will spin around with idle queue if there is nothing to render anyway.

There must be some user interaction with it, it can't be trimmed down to something like "enabled/disabled" because it can't predict gameplay sections which suddenly are way more demanding than others, in this case an FPS drop can occur until it readjusts itself. But this is a problem the user can solve by looking at the log and seeing what values it actually ends up using after the performance drop and setting it to the global max value. Same for audio issues at high values - something we can't detect but the user can. Also "inactive rendering" detection doesn't really work for audio or loading screens (in loading not much rendering occurs but the PPU/SPU are fully active, so in this case loading is lengthen much if using rendering-based adjustments) either and it breaks down horribly, it needs to be spaced-out equally along the frame time to prevent issues.

There must be some user interaction with it, it can't be trimmed down to something like "enabled/disabled" because it can't predict gameplay sections which suddenly are way more demanding than others, in this case an FPS drop can occur until it readjusts itself. But this is a problem the user can solve by looking at the log and seeing what values it actually ends up using after the performance drop and setting it to the global max value. Same for audio issues at high values - something we can't detect but the user can. Also "inactive rendering" detection doesn't really work for audio or loading screens (in loading not much rendering occurs but the PPU/SPU are fully active, so in this case loading is lengthen much if using rendering-based adjustments) either and it breaks down horribly, it needs to be spaced-out equally along the frame time to prevent issues.

This diminishes the usability drastically. Users are trying to "pick up and play" and will usually not do things like looking at logs to optimize performance. That's something developers do, not gamers.
The reason I point out rendering is that there is a fixed amount of content to draw each frame, we should be able to tell when there is nothing to do and save on cpu power if we're not actively working to put something onto the display.
Basically, new code is always a negative and we need strong positives to balance it out. There is potential in the idea here, I'm just convinced this can be made more accessible to the end user. That said, I'll play around with it and see if this can be improved. It would be a great addition as rpcs3 is power constrained on handhelds.

Made this setting much less obscure and recommends values less than 50 so most of the users won't need to do much thinking with it. Also, maximum value has been reduced to 300.

Improved analysis to make FPS drops much shorter even on high values and made logging more useful for users who do want to tinker with it.

Fixed the QT bug.

This could probably even improve performance on some devices that are thermally limited.

This seems to cause visual corruption in Ni No Kuni when set to 25 & you're in the Dark Forest area. Here's a save file for testing. Should be immediately apparent, it looks like portions of assets blink out of existence for a frame.

BLUS30947_00002.zip

@Nicholas-Steel Hi, try to set "Allow RSX CPU Preemptions: false" in game config file when using this feature.

@Nicholas-Steel Hi, try to set "Allow RSX CPU Preemptions: false" in game config file when using this feature.

@elad335 That had no effect. This is what it looks like: https://www.youtube.com/watch?v=0j38bggAkp0

config_BLUS30947.zip (the change elad335 mentioned is not present in this copy of the config but I did test it)